Taking the distributed nature of cooperative work seriously

and evolve through a process of local adaptations. The challenge is thus to provide a CSCW environment which supports the construction and use of computational coordination mechanisms which are robust in view of the distributed nature of cooperative work. For CSCW facilities to be effective and viable, the inherently distributed nature of cooperative work must matched by a radically distributed environment. On the basis of a scenario derived from field studies, the paper describes a CSCW environment which supports the distributed construction and use of malleable and linkable coordination mechanisms. 1. A real-world scenario Consider a team of software designers who are engaged in developing a large software system. The design task poses a major challenge to them as they have no established routines and conventions for handling a cooperative design effort of this size and for ensuring that the individual designers’ contributions can be integrated. Cooperative work is constituted by mutual interdependence of activities. However, by involving multiple actors cooperative work is inherently and inexorably distributed. No agent is all-knowing and all-powerful. Actors must act and interact on the basis of partial knowledge and are, accordingly, partially autonomous in their work. In order to manage the complexity of such a project, the software designers have devised and introduced a number of procedures, conventions and related artifacts to help them coordinate their cooperative effort. For the sake of simplicity, we will limit the scenario to four artifacts and associated procedures and conventions used in the context of software testing.1 The myriad interdependent and yet distributed activities must be articulated to prevent the cooperative effort from ‘trashing around chaotically’, to use Waldrop’s apt expression [16, p. 109]. They must be coordinated, aligned, meshed, etc. The obvious and fundamental way to do that is to facilitate mutual awareness among actors, for instance, by having actors working in the same room or by providing some multi-media emulation of a ‘shared space’. The Project Schedule. A Project Schedule was introduced, as a paper based artifact, to capture and display the relationships between actors, responsibilities, tasks, and deadlines. The latter are mainly related to the particular notion of the ‘platform period’ within which all software designers are coding and integrating their bits and pieces. For each such platform period, one of the designers is appointed Platform Master which implies that he or she will be responsible for updating information on changes made to the software and for ensuring that the software is tested and corrected before it is released. Moreover, before the software is released as a ‘platform’ for further development, the Platform Master updates the project schedule is with revised plans and tasks for the next period. However, task interdependencies are often of an order of complexity where the provision of facilities for mutual awareness and ad hoc interactions is insufficient. Other means are required which make task interdependencies tractable. We call such means coordination mechanisms [12]. A coordination mechanism is, simply put, a coordinative protocol with an accompanying artifact, such as, for instance, a standard operating procedure supported by a certain form. A coordination mechanism offers a ‘precomputation’ [11] of task interdependencies and is thereby instrumental in reducing the space of possibilities facing a competent actor in a given situation. However, the distributed nature of cooperative work is not eradicated by coordination mechanisms. They are merely local and temporary closures which assist actors in managing an otherwise overwhelming complexity. They are used in a distributed way The Directory. The directory structure of the software module repository provides a classification scheme for enabling distributed storage and retrieval of tested software 1 Our scenario is based upon field studies at Foss Electric in Denmark. In these field studies different aspects of a major design effort, the ‘S4000 project’, were investigated. The field study findings have been reported elsewhere [e.g., 2]. Proceedings of the 6th Euromicro Workshop on Parallel and Distributed Processing, Madrid, January 21-23 1998, IEEE Computer Society Press, Los Alamitos, Calif., 1998, pp. 295-301 modules. In addition, it provides a common standardized conceptualization of essential aspects of the field of work, namely the software architecture. All designers can relate to this when communicating and coordinating their activities. each protocol can be constructed relatively independently of the others. Thus, in designing a protocol for a specific purpose, actors do not need to have an overview of the totality of work processes in the setting at large. In fact, in settings such as our scenario it is unlikely that anybody should have such an overview. Hence, because such protocols can be designed and introduced to serve limited purposes, the array of interlaced protocols of the work arrangement at large can be designed and maintained in a distributed manner. It evolves through a process of local actions and interactions. The Bug Report Form. The Bug Report Form is developed to handle the process of software testing and as an artifact it is a simple paper form. When a new bug is detected by anyone involved in testing the software, a new bug report form is initiated and filled-in with a preliminary description and diagnosis of the problem. The designer responsible for diagnosing and classifying all reported bugs then determines the presumably culpable module and, by implication, the designer responsible for that module and specifies the platform integration period by which the bug should be corrected, and classifies the bug according to its perceived severity (as seen from a software reliability perspective). Finally, each designer is responsible for fixing the problems and reporting back to the Platform Master, i.e., the designer responsible for the next software module integration and verification period. Furthermore, there is a specific and crucial relationship between protocol and artifact which is absent from the concept of workflows. (1) The protocol is objectified by the artifact which thus gives a certain permanence to the protocol. That is, it conveys the stipulations of the protocol in a situation-independent manner. (2) The artifact serves as an intermediary between actors in that it mediates information about state changes to the protocol as it is being executed. In the case of the bug report, for example, the state of the artifact changes according to the changing state of the protocol. As in the case of any workflow, the form is transferred from one actor to another and this change of location transfers to the particular actor the specific responsibility of taking a specific action on this particular bug. However, at each step in the execution of the protocol, the form is annotated and the thereby updated form retains and conveys this change to the state of the protocol to the other actors. That is, a change to the state of the protocol induced by one actor (a tester reporting a bug, for example) is conveyed to other actors by means of a visible and durable change to the artifact. In so far, the artifact can be said to provide a ‘shared space’, to use a popular CSCW term, albeit with important restrictions: it is a highly restricted space with a structure that reflects salient features of the protocol, and it is only ‘shared’ locally, within the context of the particular instantiation of the protocol. The Binder. All bug forms are filed in a public repository (‘the binder’) which is organized according to the status of the bugs. The forms collected in the binder are successively re-classified and re-filed according to decisions made by the designers, messages concerning specific bugs, results from the verification of the reported corrections from the platform integration period, etc. From time to time, the software designers will experience situations where they need to modify a protocol they have devised and adopted as it does provide adequate coordination. These modifications may be merely local and temporary. For example, a tester will occasionally inform a software designer directly of a detected bug, without filling-in a bug report form and initiating a new instance of the protocol. On the other hand, the actors may want to change the protocol for good. The software designers may, for example, introduce the role of a project manager in the protocol. It is obvious from our description that the different protocols interact in the sense that information or event notifications generated locally propagate across protocols, in order to meet the integration objectives and to solve critical situations. (3) It is this close relationship between protocol and artifact which makes local control of the execution and evolution of the protocol feasible. By objectifying the protocol, the artifact also delimits the scope of the protocol in a tangible way. The very materiality of the artifact thus facilitates a distributed, incremental evolution of the entire population of protocols. Moreover, also due to its materiality the artifact facilitates a (restricted as well as focused) mutual awareness among actors which, inter alia, enables them to decide whether or not to deviate from the protocol in the face of contingencies. 2. Analysis The assemblage of protocols described in this scenario could, of course, be modelled as an integrated ‘workflow’. This would, however, be utterly misleading in view of the distributed nature of cooperative work. In short, the artifact plays a crucial role for the protocol by objectifying it, by representing salient features, by mediating the state of the protocol, etc. The artifact and the protocol work ‘hand in glove’. First of all, each of the protocols is devised to serve specific purposes in the setting. They address a very narrow set of coordinative activities. They are local and temporary closures. Of course, the protocols intersect at various points and therefore need to be aligned by the actors in the course of their work. Anyway, while the protocols are interlaced, they are only loosely coupled. Because of that,